GUMS 1 : A General User Modeling System

This paper describes a general architecture of a domain independent system for building and maintaining ling term models of individual users..The user modeling system is intended Io provide a well defined set of services for an application system which is interacting with various users and has a need to build and maintain models of them. As the application system interacts with a user, it can acquire knowledge of him and pass that knowledge on 1o the user model maintenance system for incorporation. We describe a prototype general user modeling system (hereafter called GUMSI) which we have implemented in Prolog. This system satisfies some of'the " desirable characteristics we discuss. In l roduc t ion The Need for User Model ing Systems which attempt to interact with people in an intelligent and cooperative manner need to know many things about the individuals with whom they are interacting. Such knowledge can be of several dilferent varieties and can be represented and used in a number of different ways. Taken collectively, the information that a.system has of its users is typically refered to as its user model. This is so even when it is distributed through out many components of the system. Examples that we have been involved with include systems which attempt to provide help and advice [4, 5, 15], tutorial systems [14], and natural language interlaces [16]. Each el these systems has a need to represent information about individual users. Most el the information is acquired incrementaly through direct observation and/or interaction. These systems also needed to infer additional facts about their users based on the directly acquired informalion. For example, the WIZARD help system [4, 15] had to represent which VMS operating system objects (e.g. commands, command qualifiers, concepts, etc) a user was familiar with and to infer which other objects he was likely to be familiar with. We are evolving the e design of a general user model maintenance system which would support the modeling needs of the projects mentioned above. The set of services which we envision the model maintenance system pedorming includes: • maintaining a data base of observed facts about the user. • infering additional true facts about the user based on the observed facts. • infering additional facts which are likely to be true based on default facts and default roles. • informing the application system when certain facts can be infered to be true or assumed true. • maintaining the consistency of the model by retracting default information when it is not consistent with the observed facts. providing a mechanism for building hierarchies of stereotypes which can form initial, partial user models. • recognizing when a set of observed lacts about a user is no longer consistent with a given stereotype and suggesting alternative stereotypes which are consistent. This paper describes a general amhitectura for a domain independent system for building and maintaining long term models of individual users. The user mocleling system is intended to provide a well delined set of services for an app/ication system which is interacting with various users and has a need to build and maintain models of Ihenr~ As Ihe application system interacts with a user, it can acquire knowledge of him and pass that knowledge on to the user model maintenance system for incorporation. We describe a prototype genera/user modeling system (hereafter called GUMS1) which we have implemented in Prelog. This system satisfies some el lhe desirable characteristics we discuss. What is a User Model? The concept of encorporating user models into interactive systems has become common, but what has been meant by a user model has varied and is not always clear. In trying to specify what is being refered to as a user model, one has to answer a number of questions: who is being modeled; what aspects of the user are being modeled; how is the model to be in'rtially acquired; how will it be maintained; and how will it be used. In this section we will attempt to characterize our own approach by answering these questions. Who is being modeled? The primary distinctions here are whether one is modeling individual users or a class of users and whether one is attempting to construct a short or long term model. We are interested in the aquisition and use of lonq ter m models of individual users. We want to represent the knowledge and beliefs of Individuals end to do so In a way that results in a persistent record which can grow and change as neccessary. It will be neccessary, of course,to represent generic facts which are true of large classes (even all) of users. In particular, such facts may include inference rules which relate a person's belief, knowledge or understanding of one thing to his belief, knowledge and understanding of others. For example In the context of a timeshared computer system we may want to include a rule like: ff a user U believes that machine M is running, then U will believe that it is possible for him to log onto M. It is just this sort of rule which is required in order to support the kinds el cooperative interactions studied in [6] and [7], such as the following: